home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-3449 / text / stproger.txt < prev    next >
Text File  |  1992-02-24  |  25KB  |  712 lines
  1.  
  2.  
  3. Message #1 of 37 on 'US ST Programmers' 
  4. Date : 23 Oct 91  00:21:02
  5. From : Thierry Bousch
  6. To   : John Charles
  7. Subj : Re: GFA Basic & ACCS
  8.  
  9. In a message of <17 Oct 91  23:07:00>, John Charles (2:252/25) writes:
  10.  
  11.  JC> Most of the prog I'm trying to write works OK but I can't  get it to
  12.  JC> recognise
  13.  JC> when an DESK ACC has been used so that the screen can be refreshed
  14.  JC> automatically instead of leaving that blank grey rectangle which so
  15.  JC> many progs
  16.  JC> show after an ACC has been used.
  17.  
  18. Remember: if you're writing a GEM program, you should never write directly onto
  19. the screen, but in a window (the screen doesn't belong to you!). If you do so,
  20. you'll never have trouble with desk accessories: they will automagically send a
  21. WM_REDRAW message to your application: see the GEM Book for more details.
  22.  
  23. Thierry
  24.  
  25. --- LED 1.00
  26.  * Origin: Le Chiffre, Aix-en-Provence, France (2:320/100.9)
  27.  
  28.  
  29. Message #2 of 37 on 'US ST Programmers' (Rec'd)
  30. Date : 23 Oct 91  20:35:20
  31. From : Peter Habing
  32. To   : Tony Barker
  33. Subj : Starwars
  34.  
  35.  
  36. Hello Tony,
  37.  
  38.  
  39. Did you write Starwars demo for TT? If so, Then I want to say, "A very nice
  40. Demo!".This is on HD en stays there!
  41.  
  42.  
  43. Ciao Peter.
  44.  
  45. --- ScanMail 0.56bta
  46.  * Origin: (NL)Dutchman Point # 15 on TT 030/8 (2:280/3.15)
  47.  
  48.  
  49. Message #3 of 37 on 'US ST Programmers' (Local)
  50. Date : 30 Oct 91  13:40:48
  51. From : Tony Barker
  52. To   : Peter Habing
  53. Subj : (2) Re: Starwars
  54.  
  55. > Hello Tony,
  56.  
  57.  
  58. > Did you write Starwars demo for TT? If so, Then I want to say, "A very
  59. > nice Demo!".This is on HD en stays there!
  60.  
  61.  
  62. > Ciao Peter.
  63.  
  64. I did indeed, and in a big rush. There is a bit of a story that goes with it as
  65. well.
  66. First I only had about 2 nights to do it in as I had a TT on loan from Atari
  67. Australia, so it's not as good as it may have been. The reason I was in a rush
  68. also was to get the demo in to Atari US for a competition they were running. I
  69. made it in time but they disqualified it saying they were worried about breach
  70. of copyright due to the Star wars images etc. Sooo I said fine I hereby
  71. withdraw it, it is not for public release and should never be seen by the
  72. public or anyone for that matter let alone Atari.
  73. But lo and behold it seems that Atari have let it out, officially or not I
  74. don't know or care, and have received the benefit that a reasonable demo for a
  75. new machine brings them (you know how hard it is to sell a machine with nothing
  76. to run on it.) and have obviously gone against my wishes and deprived me of a
  77. chance to win a TT but still gained themselves.
  78. Don't get me wrong I'm glad some people have seen it but it burns me up when I
  79. think that they refused me entry into the competition and still released it.
  80. Anyway, enough of my bloody whinging, I'm glad you liked it. If ever I have the
  81. time I may release another, but I'm currently deep into this paint package for
  82. the TT's 256 color mode. If you know of any publishers out there that might be
  83. interested let them know.
  84.         Tony.
  85.  
  86. --- QuickBBS ST v1.06 PR+
  87.  * Origin: Atari User Group, NSW Australia ~ +61-2-664-1303 (3:712/520.0)
  88.  
  89.  
  90.  
  91. Message #9 of 37 on 'US ST Programmers' 
  92. Date : 06 Nov 91  00:20:48
  93. From : Jon Webb
  94. To   : Daron Brewood
  95. Subj : Re: GFA & Timestamp
  96.  
  97.  > Does anyone know how to read the time/datestamp of a selected file in
  98.  > GFA basic??
  99.  
  100. There are a number of ways to do it. Easiest is:
  101.  
  102.     IF EXIST(filename$)
  103.       dostime&=WORD{FGETDTA()+22}
  104.       dosdate&=WORD{FGETDTA()+24}
  105.     ENDIF
  106.  
  107. The 'EXIST' function will load the directory entry into the DTA. You could use
  108. FSFIRST() instead, but the result is the same. DosTime& and DosDate& can be
  109. decoded as described in the GEMDOS appendix under Tgetdate() and Tgettime().
  110.  
  111. Electronic Greetings!                                      - Jon -
  112.  
  113. --- QuickNet ST v0.10 beta
  114.  * Origin: [ Quick SysOps do it with Hot Keys! ] (2:282/301.2)
  115.  
  116.  
  117. Message #10 of 37 on 'US ST Programmers' (Rec'd)
  118. Date : 06 Nov 91  00:26:04
  119. From : Jon Webb
  120. To   : Tony Barker
  121. Subj : Re: GFA Basic & ACCS
  122.  
  123.  > I have a similar interest in a solution to this problem for a project
  124.  > I'm just about finishing, written in 'C' but the idea for the solution
  125.  > should be the same, so if you make any progress or get any clever
  126.  > replies please let me know.
  127.  
  128. It boils down to this - if you allow access to desk accessories (i.e. have a
  129. menu bar), you should also use windows.
  130.  
  131. Electronic Greetings!                                      - Jon -
  132.  
  133. --- QuickNet ST v0.10 beta
  134.  * Origin: [ Quick SysOps do it with Hot Keys! ] (2:282/301.2)
  135.  
  136.  
  137. Message #18 of 37 on 'US ST Programmers' (Local)
  138. Date : 17 Nov 91  15:44:56
  139. From : Tony Barker
  140. To   : Peter Habing
  141. Subj : (12) Re: Starwars Demo
  142.  
  143. I have basically finished the paint package (about 90%) and now just have to
  144. search out a buyer. If all goes well I may release a demo version sometime in
  145. the future.
  146. I haven't yet received your post card but I do look forward to it, thanks.
  147.         Tony.
  148.  
  149. --- QuickBBS ST v1.06 PR+
  150.  * Origin: Atari User Group, NSW Australia ~ +61-2-664-1303 (3:712/520.0)
  151.  
  152.  
  153.  
  154. Message #29 of 37 on 'US ST Programmers' 
  155. Date : 29 Dec 91  00:35:36
  156. From : Simon Lindsay
  157. To   : John Charles
  158. Subj : Re: GFA Basic & ACCS
  159.  
  160. > A problem; for anybody who uses or abuses GFA Basic 3.5 on the ST:-
  161. > when an DESK ACC has been used so that the screen can be refreshed
  162. > automatically instead of leaving that blank grey rectangle which so many
  163.  
  164. The only way i have found to recognise when an accessory has been opened and
  165. shut is to have a window open, using the Openw etc commands, not the
  166. Wind_create etc.. then the messages as specified in the menu(x) section of the
  167. manual work fine.. you will get a menu 40 or 41 when an accessory is closed.
  168.  
  169. I am glad to see someone else having the same problem. I tried for a coupe of
  170. weeks to get around it, then abandoned the program entirely, then just last
  171. week, tried something different, using the methid described above.. and it
  172. worked !!!
  173.  
  174. Simon
  175.  
  176.  -- QuickBBS ST v1.06 PR+
  177. --- ScanMail 0.56bta
  178.  * Origin: Hopeful home of DeFrag. (3:680/842)
  179.  
  180.  
  181.  
  182. Message #31 of 37 on 'US ST Programmers' 
  183. Date : 07 Feb 92  18:44:40
  184. From : Bart Van.Herk
  185. To   : Magic.Alex Badalic
  186. Subj : Re: I would to like spek terminal.
  187.  
  188. In a message of <04 Feb 92  07:40:10>, Magic.Alex Badalic (2:331/317.1) writes:
  189.  
  190.  > That is the main problem with all the speech sinthetyzers I've seen up
  191.  > to now: they all stick to the original language phonemes, and none of
  192.  > them can be programmed for us in an external, custom made module...
  193.  
  194. The problem is that not only are the sounds different for every language, also
  195. the interpretation of them within words. You would have to rewrite the complete
  196. algorithm for every language, not just replace the sounds. For example, the
  197. word 'zeventien' (seventeen) in Dutch has three 'e's, the first is pronounced
  198. like the 'a' in take, the second like the 'u' in bum, while the third is not
  199. pronounced at all but modifies the preceding 'i' to sound like the 'ee' in
  200. 'teen', instead of like the 'i' in 'kid'.
  201.  
  202. Hartelijke groeten, * Bart *
  203.  
  204. --- LED 1.00t
  205.  * Origin: Bart's point, Rotterdam NL (2:281/801.5)
  206.  
  207.  
  208.  
  209. Message #35 of 37 on 'US ST Programmers' 
  210. Date : 09 Feb 92  10:57:04
  211. From : Bart Van.Herk
  212. To   : Michael Fung
  213. Subj : Re: C absolute call
  214.  
  215. In a message of <03 Feb 92  14:01:16>, Michael Fung (6:600/15) writes:
  216.  
  217.  > Want to find out how to make a direct access to a memory location. For
  218.  > example, if I want to find/set the contents of address $4f2, how do I
  219.  > do it in C code??
  220.  
  221. char * p = (char *)0x4f2 ;
  222. char x ;
  223. x = *p ;
  224.  
  225. Hartelijke groeten, * Bart *
  226.  
  227. --- LED 1.00t
  228.  * Origin: Bart's point, Rotterdam NL (2:281/801.5)
  229.  
  230.  
  231. Message #36 of 37 on 'US ST Programmers' 
  232. Date : 09 Feb 92  17:45:14
  233. From : Diederik Hoogenboom
  234. To   : Michael Fung
  235. Subj : Re: C absolute call
  236.  
  237. In a message of <03 Feb 92  14:01:16>, Michael Fung (6:600/15) writes:
  238.  
  239.  MF> Hello all C programmers,
  240.  MF> 
  241.  MF> Want to find out how to make a direct access to a memory location.
  242.  MF> For example, if I want to find/set the contents of address $4f2, how
  243.  MF> do I do it in C code??
  244.  MF> 
  245.  MF> Greetings,
  246.  MF> Michael Fung
  247.  
  248. If the value on $4f2 is for example an integer you can do it like this:
  249.  
  250. value=*(int*)(0x4f2);
  251.  
  252. But before you do this you have to be sure that you are in supervisor-mode,
  253. otherwise a buserror will occur. You can use Supervisor (gemdos 32) for that.
  254.  
  255.         Greetz... ~Diederik~
  256. --- Bermuda v1.00
  257.  * Origin: Galtan Six - We are the worst!! (2:281/801.9)
  258.  
  259.  
  260. Message #37 of 37 on 'US ST Programmers' 
  261. Date : 08 Feb 92  14:11:22
  262. From : Peter Kocourek
  263. To   : Michael Fung
  264. Subj : Re: C absolute call
  265.  
  266. In a message of <03 Feb 92  14:01:16>, Michael Fung (6:600/15) writes:
  267.  
  268.  MF> Want to find out how to make a direct access to a memory location. For
  269.  MF> example, if I want to find/set the contents of address $4f2, how do I
  270.  MF> do it in C code??
  271.  
  272. Simple (well, almost):
  273.  
  274.    x = *(int *)0x4F2;
  275.  
  276. will read an int from address $4f2, but you must execute this in
  277. supervisor-mode, so you'll need something like:
  278.  
  279.    old_sp = Super(0L);
  280.    x = *(int *)0x4F";
  281.    Super(old_sp);
  282.  
  283. where old_sp is a long. To read anything other than an int, cast it to that
  284. type: x= *(long *)0x4F2 etc.
  285.  
  286.  
  287. YHS:QSI!
  288. --- Bermuda v1.00
  289.  * Origin: On & On & On: The Bright Blue No Turning Back Point (2:282/301.17)
  290.  
  291.  
  292. Message #1 of 21 on 'NeST 'C' Programming' 
  293. Date : 03 Dec 91  14:31:20
  294. From : Dallas 
  295. To   : All
  296. Subj : C compilers
  297.  
  298. I have Turbo C++ and it takes up 6megs of hd space and has more bells and
  299. whistles than a person teaching themselves can handle.  I'm looking for a more
  300. "standard" compiler that doesn't take up as much room and  is lacking in bells
  301. and whistles that I'll never use.
  302.  
  303. --- FIDOdoor 2.5.1 [Registered]
  304. g themselves can handle.  I'm looking for a more "standard" compiler that
  305. doesn't take up as much room and  is lacking in bells and whistles that I'll
  306. never use.
  307. 90:3000/135)
  308.          3000/135 * Origin: DeadHead Ed's STeal Your Face HST/DS<908-920-7981>
  309. (90:3000/489)
  310.          3/0 * Origin: AutoBoss_[Fnet19]_(US CrossNet GateWay)_Hst/v42/v32
  311. (90:3/0)
  312.          2/0 * Origin: My Little Phoney [Atari ST], (+44)(0)793-849044
  313. (90:1004/0)
  314.  
  315. Message #6 of 21 on 'NeST 'C' Programming' 
  316. Date : 26 Jan 92  23:37:54
  317. From : Gary Gregson
  318. To   : ALL
  319. Subj : RCS.PRG
  320.  
  321. Hi Guys,
  322.         I don't know wether anybody out there has any info on the resource
  323. construction kit program.....but if they do I'd love to get my hands on it.
  324. For normal dialog construction etc. it seem pretty straight forward, but
  325. recently I've been trying to include some Icons and free images into my
  326. resources but I can't work out the LOAD formats. Anyone got any idea what they
  327. are? I've tried straight bitmaps, .XBM (C ascii type format), Hex dumps,
  328. Iconblock definitions etc..etc. But all I get is garbage and out of memory
  329. errors!!! I've worked round it by coding the images into the my main C sources
  330. and then placing them into the tree after resource load.. but this is a bit
  331. tedious.
  332.  
  333. Any info or help will be most appreciated.
  334.  
  335.                                             Gary
  336.  
  337. --- TIDY_UP 1.3 dfad
  338.  * Origin: STUN point 6 (90:1008/104)
  339.  
  340.  
  341. Message #7 of 21 on 'NeST 'C' Programming' 
  342. Date : 27 Jan 92  19:49:00
  343. From : Steve Caple
  344. To   : Adam Holyoak
  345. Subj : (2) Re: C compilers
  346.  
  347. Gety either Pure-C, which I haven't got my sticky mits on yet, or Lattice C
  348. V5.5 when it appears... Pricey, but the best 2 about i think... I use Lattice
  349. at the moment, but I'm gonna Switch as soon as I can Track down Pure-C ;-))
  350.  
  351. If you can't already write C progs, start off with Sozobon C... it's PD, and
  352. we've all got a copy of it somewhere!!
  353.  
  354.                             Ste\/e
  355.  
  356. --- TIDY_UP 1.31 21ad
  357.  * Origin: ~///Reachout Crewe~<+44-(0)270-583-287> (90:5000/1050)
  358.  
  359.  
  360. Message #8 of 21 on 'NeST 'C' Programming' 
  361. Date : 27 Jan 92  19:31:00
  362. From : Steve Caple
  363. To   : Gary Gregson
  364. Subj : (6) RCS.PRG
  365.  
  366.  In message 1050/25/5, Gary Gregson writes:
  367.  
  368.  > :From Gary Gregson
  369.  > Hi Guys,
  370.  >         I don't know wether anybody out there has any info on the resour
  371.  > construction kit program.....but if they do I'd love to get my hands on
  372.  >
  373.  > For normal dialog construction etc. it seem pretty straight forward, but
  374.  > recently I've been trying to include some Icons and free images into my
  375.  > resources but I can't work out the LOAD formats. Anyone got any idea wha
  376.  > they are? I've tried straight bitmaps, .XBM (C ascii type format), Hex
  377.  > dumps, Iconblock definitions etc..etc. But all I get is garbage and out
  378.  > memory errors!!! I've worked round it by coding the images into the my m
  379.  > C sources and then placing them into the tree after resource load.. but
  380.  > this is a bit tedious.
  381.  >
  382.  > Any info or help will be most appreciated.
  383.  >
  384.  >                                             Gary
  385.  >
  386.  >  * Origin: STUN point 6 (90:1008/104)
  387. Hi Guy...
  388. Have you got DEGAS ELITE??
  389. If so run up a 64x64 ICN file and save it off... it'll load straight into
  390. RCS2 as an image, or as an ICON... you can use othersizes for Free Images
  391. There are ICN editors around in the PD, but I always used DEGAS, cos I was
  392. too idle to learn to use anything else .. hehe
  393.     IT works guy.... check out any of my ChipRat Software stuff that's
  394. flying about in PD, I did all those with it!!
  395.  
  396. Ste\/e ... who's gonna get an ICN editor for RCS2 someday....
  397.  
  398. --- TIDY_UP 1.31 21ad
  399.  * Origin: ~///Reachout Crewe~<+44-(0)270-583-287> (90:5000/1050)
  400.  
  401.  
  402.  
  403. Message #10 of 21 on 'NeST 'C' Programming' 
  404. Date : 27 Jan 92  20:11:46
  405. From : Peter Kocourek
  406. To   : Geoff Gunner
  407. Subj : (3) Re: ANSI 'C'
  408.  
  409. In a message of <24 Jan 92  20:50:00>, Geoff Gunner (90:5000/1050) writes:
  410.  
  411.  GG> Hiya Steve !  Well, dunno about Turbo 'C' - I've got a few issues of
  412.  GG> the U.K C users group magazine; it may be in there.  Anyway, I didn't
  413.  GG> think there *WAS* an ANSI 'C' for the ST yet.  *OR* a C++ (sniff,
  414.  GG> sob!). Apparently Lattice are bringing out a new version - it may be
  415.  GG> both ANSI and C++ !! (now there's something to drool over.)
  416.  
  417. There is an ANSI C, and it's now called Pure C, the successor to Turbo C.
  418. There's also GNU C++ (or whatever it's called) for the ST.
  419.  
  420.  
  421. YHS:QSI!
  422. --- Bermuda v1.00
  423.  * Origin: Chastity is its own punishment. (90:4001/0.17)
  424.  
  425.  
  426. Message #11 of 21 on 'NeST 'C' Programming' 
  427. Date : 29 Jan 92  12:31:34
  428. From : Steven Green
  429. To   : Peter Kocourek
  430. Subj : (10) Re: ANSI 'C'
  431.  
  432. Here's a small comparison between ST ANSI compilers (they may not be strictly
  433. ANSI, but they are close enough as far as most people are concerned.. besides
  434. It concerns a program to generate file lists on my BBS.
  435.  
  436.                            |  Pure C | Lattice C5  | Gnu C++     |
  437.  >-------------------------+---------+-------------+-------------+
  438.     Program Size (bytes)   |  12907  | 20908       | 33411       |
  439.  >-------------------------+---------+-------------+-------------|
  440.   Execution Time (seconds) |  36.54  | 47.11       | 43.24       |
  441.  >-------------------------+---------+-------------+-------------|
  442.   Compile&Link time (sec)  |   9.9   | 30.18       | 40.71       |
  443.    (without optimisation)  |   ---   | 22.89       | 35.88       |
  444.  >-------------------------+---------+-------------+-------------.
  445.  
  446.   This was timed using Craft's time function (PureC's compile time was
  447.   timed with a stop watch since it was done from the integrated
  448.   environment) and was the time to process my file lists consisting of
  449.   2004 files in 18 areas, producing an allfiles list of 252254 bytes and a
  450.   newfiles (60 days) of 24794 bytes. All versions produced identical
  451.   files. Lattice and Gnu both had optimisation enabled (PureC optimises by
  452.   default).  A Ramdisk was used for temporary files for Lattice and GnuC.
  453.  
  454. - STeVeN
  455.  
  456. --- ScanMail 0.65 beta
  457.  * Origin: My Little Phoney, +44-793-849044 (90:1004/0.2)
  458.  
  459.  
  460. Message #12 of 21 on 'NeST 'C' Programming' 
  461. Date : 31 Jan 92  11:35:06
  462. From : Steven Green
  463. To   : Iain Paton
  464. Subj : Re: TOS v.3.01?
  465.  
  466. In a message of <29 Jan 92  15:53:34>, Iain Paton (2:259/5) writes:
  467.  
  468.  IP> Compact code doesn't always imply speed, more often it implies lack
  469.  IP> of speed. IME something programmed to run _fast_ will take up more
  470.  IP> space. OTOH efficient code is the best tradeoff between speed/size.
  471.  IP> Most compilers produce broadly similar code, but some waste less time
  472.  IP> on things that don't really need doing, hence smaller code - doing
  473.  IP> the same thing - can seem to run faster..
  474.  
  475. I don't know, this may be true with hand coded assembly language, where you
  476. might use techniques such as unwrapping loops, using big look up tables, etc,
  477. but not with code generated by compilers, I think in general size and speed are
  478. related. e.g. take a simple example:
  479.   func(1,20,0);
  480. Some compilers will generate code such as:
  481.    move #1,d0        ; Some compilers may use moveq here.
  482.    move d0,-(sp)
  483.    move #20,d0
  484.    move d0,-(sp)
  485.    move #0,d0        ; Again a moveq or a clr could be used here
  486.    move d0,-(sp)
  487.    jsr _func
  488.    add.l #4,sp
  489. Others will do it in the faster and more compact:
  490.    move #1,-(sp)
  491.    move #20,-(sp)
  492.    clr.w -(sp)
  493.    jsr _func
  494.    addq.l #4,sp
  495. Others will replace the move # with moveq.
  496. PureC or Lattice using the -rr switch would do it like:
  497.    moveq #1,d0
  498.    moveq #2,d1
  499.    clr d2
  500.    bsr _func
  501.  
  502. Even cases of built in functions can be the same sort of size as calling a
  503. function.
  504.   strcpy(s,s1);
  505. might compile to:
  506.     pea s1            ; time/size depends on s1
  507.     pea s             ; time/size depends on s
  508.     jsr _strcpy       ; 3 words
  509.     lea 8(sp),sp      ; 2 words
  510. but is slower and takes more memory than the hard coded:
  511.     lea s,a0          ; same size as pea s
  512.     lea s1,a1         ; same size as pea s1
  513. @@loop:
  514.       move.b (a1)+,(a0)+ ; 1 word
  515.     dbeq @@loop          ; 2 words
  516. Thus the faster hard coded version is 4 bytes shorter!
  517.  
  518. Another common case is something like:
  519.   char c = *s++;
  520. This could be as simple as:
  521.   If s and c are register variables then this could be as short as:
  522.     move.b (a0)+,d0
  523.   But inefficent compilers will do all sorts of things with effective
  524.   addresses and things, in some cases you may even get something as
  525.   convoluted as:
  526.     lea <s>,a0
  527.     move.l (a0),a1
  528.     move.b (a1),d0
  529.     ext.w d0
  530.     move d0,-(sp)
  531.     move.l (a0),d0
  532.     addi.w #1,d0
  533.     move.l d0,(a0)
  534.     move (sp)+,d0
  535. I remember some years ago looking at the output of a CP/M 8080 C Compiler and
  536. its output was just full of horrendous indirections of DE and HL registers and
  537. pushing and popping, bearing no relation to what a real assembler program would
  538. have done.  It wasn't until I started using 8086 machines that I really trusted
  539. C compilers enough to generate efficient code and even now I estimate that
  540. compiled code is at least twice as big and half as fast as hand coded assembly
  541. language.
  542.  
  543. - STeVeN
  544.  
  545. --- ScanMail 0.60bta
  546.  * Origin: My Little Phoney, +44-793-849044 (90:1004/0.2)
  547.  
  548.  
  549. Message #13 of 21 on 'NeST 'C' Programming' 
  550. Date : 31 Jan 92  17:55:08
  551. From : Peter Kocourek
  552. To   : Steven Green
  553. Subj : Trigraphs
  554.  
  555. In a message of <29 Jan 92  12:31:34>, Steven Green (90:1004/0.2) writes:
  556.  
  557.  SG> Here's a small comparison between ST ANSI compilers (they may not be
  558.  SG> strictly ANSI, but they are close enough as far as most people are
  559.  SG> concerned.. besides what exactly IS a trigraph???!).  It concerns a
  560.  
  561. A trigraph is a (on the ST useless) bit compatibility maintaining feature, for
  562. the benefit of very old terminals, which do not have characters such as {}~\
  563. etc. If I remember correctly, trigraphs replace these with sequences of three
  564. characters, such as //( for { or something like that. You can safely forget
  565. about them.
  566.  
  567. YHS:QSI!
  568. --- Bermuda v1.00
  569.  * Origin: Cobol programmers are down in the dumps. (90:4001/0.17)
  570.  
  571.  
  572. Message #14 of 21 on 'NeST 'C' Programming' 
  573. Date : 01 Feb 92  20:33:36
  574. From : Adam Holyoak
  575. To   : Steve Caple
  576. Subj : (7) Re: C compilers
  577.  
  578. > and we've all got a copy of it somewhere!!
  579.  
  580. Hi Steve!
  581. Yes I too have a copy of sozobon C and it is a great PD compiler. I think I
  582. will get the Lattice C v5.5. I have heard from many people it is the best.
  583. Currently I use Sozobon, Mark Johnson and Turbo C.
  584. See ya,
  585.  
  586. Dolphin.
  587.  
  588. --- QuickBBS ST v1.06
  589.  * Origin: applinit()...Think about it - STarlink BBS /|\ (0:0/0.0)
  590.  
  591.  
  592. Message #15 of 21 on 'NeST 'C' Programming' 
  593. Date : 01 Feb 92  13:07:26
  594. From : David Thomas
  595. To   : Steven Green
  596. Subj : (12) Re: TOS v.3.01?
  597.  
  598. In a message of <31 Jan 92  11:35:06>, Steven Green (90:1004/0.2) writes:
  599.  
  600.  SG> move #0,d0        ; Again a moveq or a clr could be used here
  601.  
  602. Incidentally, moveq is 2 cycles faster than clr and the same byte count...
  603.  
  604.  SG> lea s1,a1         ; same size as pea s1
  605.  SG> @@loop:
  606.  SG>  move.b (a1)+,(a0)+ ; 1 word
  607.  SG> dbeq @@loop          ; 2 words
  608.      ^^^^
  609. Wrong syntax! Maybe bne was meant?
  610.  
  611.  SG> and even now I estimate that compiled code is at least twice as big and
  612.  SG> half as fast as hand coded assembly language.
  613.  
  614. Yes, it's a pity ASM takes so much longer... But since I don't have a compiler
  615. (well, bar Gnu, Sozobon and other freeware offerings) all my standalone
  616. .PRG/.TOS/.TTP have been written using ASM... And I do like programming from
  617. the system level; there may be fewer commands, but that has the advantage that
  618. there is less to remember, and you're not digging around reference guides all
  619. the time...
  620.  
  621. Dave
  622.  
  623. --- IOSmail 0.82beta
  624.  * Origin: TheDreamMachine [DS] +44-222-341713 [2300-0800hrs] (90:1004/102)
  625.  
  626.  
  627. Message #16 of 21 on 'NeST 'C' Programming' 
  628. Date : 06 Jan 89  18:58:56
  629. From : Diederik Hoogenboom
  630. To   : Peter Kocourek
  631. Subj : (10) Re: ANSI 'C'
  632.  
  633. In a message of <27 Jan 92  20:11:46>, Peter Kocourek (90:4001/0.17) writes:
  634.  
  635.  PK> There is an ANSI C, and it's now called Pure C, the successor to
  636.  PK> Turbo C. There's also GNU C++ (or whatever it's called) for the ST.
  637.  
  638. The latter is even PD!! Although it takes quite some harddisk and memory space.
  639.  
  640.  
  641.         Greetz... ~Diederik~
  642. --- Bermuda v1.00
  643.  * Origin: Galtan Six - We are the worst!! (90:4001/2.9)
  644.  
  645.  
  646. Message #17 of 21 on 'NeST 'C' Programming' 
  647. Date : 30 Jan 92  20:43:20
  648. From : Louis Lagendijk
  649. To   : Geoff Gunner
  650. Subj : (3) Re: ANSI 'C'
  651.  
  652. Hi Geoff,
  653. In a message of <24 Jan 92  20:50:00>, Geoff Gunner (90:5000/1050) writes:
  654.  
  655.  GG> Hiya Steve !  Well, dunno about Turbo 'C' - I've got a few issues of
  656.  GG> the U.K C users group magazine; it may be in there.  Anyway, I didn't
  657.  GG> think there *WAS* an ANSI 'C' for the ST yet.  *OR* a C++ (sniff,
  658. There is even a freeware Ansi C-compiler: GNU-C. It has only one
  659. drawback: it requires a lot of memory. Preferably 2M or more. But who cares
  660. about that nowadays. There is also a (freeware ) GNU C++. Requires also at
  661. least 2M.
  662. Cheers, Louis
  663. --- Bermuda v1.00
  664.  * Origin: Louis Lagendijk, Ridderkerk (90:4001/202.5)
  665.  
  666.  
  667. Message #18 of 21 on 'NeST 'C' Programming' 
  668. Date : 02 Feb 92  14:02:48
  669. From : Iain Paton
  670. To   : Steven Green
  671. Subj : (12) Re: TOS v.3.01?
  672.  
  673. In a message of <31 Jan 92  11:35:06>, Steven Green (90:1004/0.2) writes:
  674.  
  675.  SG> In a message of <29 Jan 92  15:53:34>, Iain Paton (2:259/5)
  676.  SG> writes:
  677.  IP>> Compact code doesn't always imply speed, more often it implies
  678.  IP>> lack of speed. IME something programmed to run _fast_ will take
  679.  IP>> up more space. OTOH efficient code is the best tradeoff between
  680.  IP>> speed/size. Most compilers produce broadly similar code, but
  681.  IP>> some waste less time on things that don't really need doing,
  682.  IP>> hence smaller code - doing the same thing - can seem to run
  683.  IP>> faster..
  684.  SG>
  685.  
  686.  SG> I don't know, this may be true with hand coded assembly language,
  687.  SG> where you might use techniques such as unwrapping loops, using
  688.  SG> big look up tables, etc, but not with code generated by compilers,
  689.  SG> I think in general size and speed are related. e.g. take a simple
  690.  
  691. That's more or less what I meant, a compiler that produces better code runs
  692. faster with the same source input. You can still unwrap the loops in C or
  693. whatever too.. It depends really on how you tend to code things, I learned
  694. 'programming' in Z80 assembler and will always tend to apply what I learned
  695. there to programming elsewhere, so I still do unwrap loops for speed (and my
  696. programs probably look a mess too !)
  697.  
  698.  SG> C compilers enough to generate efficient code and even now I
  699.  SG> estimate that compiled code is at least twice as big and half as
  700.  SG> fast as hand coded assembly language.
  701.  
  702. Yes, although there must be a trade off somewhere over how fast you need it to
  703. run and how much time you have to spend writing it - that's  the only reason I
  704. moved away from assembler, I no longer have time to write the code that way,
  705. and don't have any time critical applications.....
  706.  
  707. Iain
  708.  
  709. --- TIDY_UP 1.31 8cd9
  710.  * Origin: Are you a real programmer ? (90:5001/0)
  711.  
  712.